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TYPED, PARAMETERIZED, AND EXTENSIBLE ACCESS CONTROL PERMISSIONS 

RELATED APPLICATIONS 
The present application is related to U.S. Patent Application No. 08/988,431, entitled 
5 "CONTROLLING ACCESS TO A RESOURCE", filed by Li Gong, on the equal day 

herewith, (attorney docket no. 3070-007/P2244/TJC), the contents of which are incorporated 
herein by reference. 

The present application is related to U.S. Patent Application No. 08/988,660, entitled 
"SECURE CLASS RESOLUTION, LOADING, AND DEFINITION", filed by Li Gong, on 
1 0 the equal day hercwidi, (attorney docket no. 3070-OO8/P2245/TJC), the contents of which arc 
incorporated herein by reference. 

The present application is related to U.S. Patent Application No. 08/988,439, entitled 
"PROTECTION DOMAINS TO PROVIDE SECURITY IN A COMPUTER SYSTEM", filed 
by Li Gong, on the equal day herewith, (attorney docket no. 3070-009/P2435/TJC), the 
IS contents of which are incorporated herein by reference. 
FIELD OF THE INVENTION 

The present invention relates to security mechanisms in a computer system. 
BACKGROUND OF THE INVENTION 

As the use of computer systems grows, organizations are becoming increasingly reliant 
20 upon them. A malfunction in the computer system can severely hamper the operation of such 
organizations. Thus organizations Aat use computer systems are vuUiciable to users viho may 
intentionally or unintentionally cause the computer system to malfunction. 

One way to compromise the security of a computer system is to cause the computer 
system to execute software that performs harmful actions on the computer system. There are 
25 various types of security measures that may be used to prevent a computer system fiom 

executing haimfui software. One mample is to check all software executed by the computer 
system with a " virus" checker. However, virus checkers only search for very specific software 
instructions. Many methods of using software to tamper with a computer's resources would 
not be detected by a virus cheeky. 
30 Another very common nieasure used to prevent the execution of software that tampers 

with a computer's resources is the " trusted developers approach** . According to the trusted 
developers approach, system administrators limit the software that a computer system can 
access to only software developed by trusted software developers. Such trusted developers 
may include, for example, well know vendors or in-house developers. 
35 Ftmdamental to the trusted developers approach is the idea that computer programs are 

created by developers, and that some developers can be trusted to not have produced software 
that compromises security. Also fundamental to the trusted developers approach is the notion 
that a computer system will only execute programs that are stored at locations that arc under 
control of the system administrators. 
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Recently developed methods of running applications involve the automatic and 
inunediate execution of software code loaded from remote sources over a network. When the 
remote sources include computer systems that are outside the control of system administrators, 
the trusted developers approach does not worL 
5 One attempt to adapt the trusted developers approach to systems that can execute code 

firom remote sources is referred to as the sand box method. The sand box method allows all 
code to be executed, but places restrictions on remote code. Specifically, the sand box method 
permits all trusted code full access to a computer system's resources and all remote code 
limited access to a computer system's resources. Trusted code is usually stored locally on the 
10 computer system under the direct control of the owners or administrators of the computer 
system^ who are accountable for the security of the trusted code. 

One drawback to the sandbox approach is that the approach is not very granular. The 
sandbox approach is not very granular because all remote code is restricted to the same limited 
set of resources. Very often^ there is a need to permit remote code fi'om one source access to 
IS one set of computer resources while permitting remote code from another source access to 
another set of computer resources. For example, there may be a need to limit access to one set 
of files associated with one bank to remote code loaded over a network from a source 
associated with that one bank, and limit access to another set of files associated with another 
bank to remote code loaded over a network fiom a source associated with the other bank. 
20 Providing security measures that allow more granularity than the sand box method 

involves establishing a complex set of relationships between principals and permissions. A 
principal** is an entity in the computer system to which permissions are granted. Examples of 
principals include processes, objects and threads. A " permission" is an authorization by the 
computer system that allows a principal to perform a particular action or fiinction. 
25 Establishing sets of permissions for principals that may be received firom multiple 

sources on a vast network, such as the Internet, typically requires developing complex security 
software. After such security software is developed, it must often be changed in order to meet 
changing security requirements. Often, changing security requirements entail modifying 
permissions or creating new kinds of permissions. Typically, the sectirity software of a 
30 computer system must be reprogrammed to incorporate these new kinds of permissions. 
Programming security software requires substantial effort and in-depth knowledge about a 
computer's security mechanisms and a computer's architecture. 

Based on the foregoing, it is clearly desirable to develop a method which reduces the 
effort and in-depth knowledge required to modify permissions established for the sources of 
35 code being executed by a computer system. It is further desirable to develop a method which 
reduces the effort and in-depth knowledge required to create new permissions. 
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SUMMARY OF THE INVENTION 

A method and system for providing security using typed and extensible control 
permissions is provided. According to one aspect of the invention, the establishment and 
maintenance of complex security niles are enforced in a way that takes advantage of the power 
5 and simplicity of the inheritance feature of object oriented programming. 

Specifically, a ''permission super class*" is established from which subclasses may be 
created. Objects that belong to subclasses of the permission super class represent permissions, 
and are therefore referred to as permission objects. 

The permission subclasses inherit the methods and attributes of the permission super 
10 class. According 10 one embodiment, one ofthe methods defined by the permission super 
class and inherited by the pennission subclasses is a validation method. Each permission 
subclass inherits the validation method fiom the permission super class and provides an 
implementation of the validation method. 

When the validation method is invoked for a particular permission object belonging to 
15 a permission subclass, the validation method indicates whether a given permission is 

encompassed by the permbsion represented by the particular pennission object For example, 
the validation method of a permission object POl may be invoked to determine whether the 
permission represented by another pennission object P02 is encompassed in the pennission 
represented by POl. where both POl and P02 belong to classes that descend fiom said 
20 permission super class. In this we can determine whether a pennission to perform a first 

action, represented by PO 1 , authorizes a request to perform a second action, which requires a 
second permission represented by P02, by invoking the validation method of POl to 
determine whether the first permission represents an authorization to perform the requested 
second action. 

25 According to another aspect of the invention, permissions represent actions on targets. 

Thus, a first permission object can specify a first action and a first target, and a second 
permission object can specify a second action and a second target A detetmination is made of 
the whether the pennission represented by the first permission object encompasses the 
permission represented by the second permission object based on whether the first action 

30 mq>lies the second action and the first target implies the second target In Ais we can 
determine, for example, whether a pennission to perform a first action on a first target, 
represented by the first permission object, authorizes a request to perfonn a second action on 
second target, which requires a second permission represented by the second object, by 
determining whether first action implies the second acdon, and the first target implies the 

35 second target 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not by way of limitation, in 
the figures of the accompanying drawings and in which like reference numerals refer to 
similar elements and in which: 
S Figure 1 is a block diagram of a computer system on which the present invention may 

be implemented; 

Figure 2 is a block diagram showing attributes and methods associated with a 
pennission super class and a subclass of the pemiission super class and permission objects 
belonging to the subclass of the permission super class in accordance with one embodiment of 
10 the present invention; 

Figure 3 is a flow chart showing the steps for establishing a permission super class and 
a subclass of the permission super class in accordance with one embodiment of the present 
invention; 

Figure 4 is a block diagram outlining a security mechanism using permission objects in 
1 5 accordance with one embodiment of the present invention; 

Figure S is a block diagram showing an exemplary policy file; 
Figure 6 is a block diagram showing a call stack associated with a thread and the 
protection domains containing permission objects associated with the objects rqprcsented by 
the call stack in accordance with one embodiment of the present invention; and 
20 Figure 7 is a flow chart showing steps followed by a security mechanism to determine 

whether a particular action is authorized in accordance with one embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A method and apparatus for providing typed permissions is described. In the 
25 following description, for the purposes of explanation, numerous specific details are set forth 
in order to provide a thorough understanding of the present invention. It will be apparent, 
however, to one skilled in the art that the present invention may be practiced without these 
specific details. In other instances, well-known structures and devices are shown in block 
diagram form in order to avoid unnecessarily obscuring the present invention. 
30 HARDWARE OVERVIEW 

Figure 1 is a block diagram that illustrates a computer system 100 upon which an 
embodiment of the invention may be implemented. Computer system 100 includes a bus 102 oi 
other communication mechanism for communicating information, and a processor 104 coupled 
with bus 102 for processing information. Computer system 100 also includes a main memory 
35 1 06, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 
102 for storing infomnalion and instructions to be executed by processor 104, Main memory 
106 also may be used for storing temporary variables or other intermediate information during 
execution of instructions to be executed by processes 104. Computer system 100 further 
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includes a read only memory (ROM) 108 or other static storage device coupled to bus 102 for 
storing static information and instructions for processor 104. A storage device 1 10, such as a 
magnetic disk or optical disk, is provided and coupled to bus 102 for storing information and 
instructions. 

S Computer system 100 may be coupled via bus 102 to a display 1 12, such as a cathode 

ray tube (CRT), for displaying information to a computer user. An input device 1 14, including 
alphanumeric and other keys, is coupled to bus 102 for communicating information and 
conunand selections to processor 104. Another type of user input device is cursor control 1 16, 
such as a mouse, a trackball, or cursor direction keys for commimicating direction 'mformauon 
10 and command selections to processor 1 04 and for controlling cursor movement on display 1 12. 
This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a 
second axis (e.g., y), that allows the device to specify positions in a plane. 

The invention is related to the use of computer system 100 for establishing typed 
permissions. According to one embodiment of the invention, establishing typed permissions 
IS is provided by computer system 100 in response to processor 104 executing one or more 

sequences of one or more instructions contained in main memory 1 06. Such instructions may 
be read into main memory 106 from another computer-readable medium, such as storage 
device 110. Execution of the sequences of instructions contained in main memory 106 causes 
processor 104 to perform the process steps described herein. In alternative embodiments, 
20 haid-wiied circuitxy may be tised in place of or in combination with software instructions to 
implement the invention. Thus, embodiments of the invention are not limited to any specific 
combination of hardware circuitry and software. 

The term "computer-readable medium** as used herein refers to any medium that 
participates in providing instructions to processor 104 for cxccxition. Such a medium may take 
25 many forms, including but not limited to, non-volatile media, volatile media, and transmission 
media. Non-volatile media includes, for example, optical or magnetic disks, such as storage 
device 1 10. Volatile media includes dynamic memory, such as main memory 106. 
Transmission media includes coaxial cables, copper wire and fiber optics, including die wires 
that comprise btis 102. Transmission media can also take the form of acoustic or light waves, 
30 such as those generated during radio-wave and infia-red data communications. 

Common forms of computer-readable media include, for example, a floppy disk, a 
flexible disk, hard disk, magnetic tape, or any otiier magnetic medium, a CD-ROM, any otiier 
optical medium, punchcards, papertape, any other physical medium vn\h patterns of holes, a 
RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a 
3 5 carrier wave as described hereinafter, or any other medium ftom which a computer can read- 
Various forms of computer readable media may be involved in carrying one or more 
sequences of one or more instructions to processor 104 for execution. For example, the 
instructions may initially be carried on a magnetic disk of a remote computer. The remote 
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computer can load the instnicdoos into its dynamic memory and send the instiuctions over a 
telephone line using a modem. A modem local to computer system 100 can receive the data on 
the telephone line and use an infra-red transmitter to convert the data to an infira-red signal. An 
infia-red detector coupled to bus 102 can receive the data carried in the infra-red signal and 
5 place the data on bus 1 02. Bus 102 carries the data to main memory 1 06. from which processor 
104 retrieves and executes the instructions. The instructions received by main memory 106 may 
optionally be stored on storage device 1 10 eidier before or after execution by processor 104. 

Computer system 100 also includes a communication interface 1 18 coupled to bus 
102. Communication interface 1 1 8 provides a two-way data conununicaiion coupling to a 
10 network link 120 that is connected to a local nctworic 122. For example, communication 
interface 1 18 may be an integrated services digital network (ISDN) card or a modem to 
provide a data coimnunication coimection to a corresponding type of telephone line. As 
another example^ commtmication interfiace 118 may be a local area network (LAN) card to 
provide a data communication cormecdon to a compadble LAN. Wireless links may also be 
15 implemented. In any such implementation, communication interface 1 1 8 sends and receives 
electrical, electromagnetic or optical signals that carry digital data streams representing 
various types of informatiorL 

Network Hnlc 120 typically provides data communication through one or more 
networks to other data devices. For example, network link 120 may provide a coimection 
20 through local network 122 to a host computer 124 or to data equipment operated by an 

Internet Service Provider (ISP) 126. ISP 126 in turn provides data communication services 
through the worid wide packet data communication network now commonly referred to as the 
"Internet" 128. Local network 122 and Internet 128 both use electrical, electromagnetic or 
optical signals that carry digital data streams. The signals through the various networks and 
25 the signals on network link 120 and through communication interface 1 1 8, which cany the 
digital data to aiKl from computer system 1 00, are exemplary forms of carrier waves 
transporting the information. 

Computer system 100 can send messages and receive data, including program code, 
through the network(s), networic link 120 and conmiunication interface 118. In the Internet 
30 example, a server 1 30 might transmit a requested code for an application program through 
Internet 128, ISP 126, local network 122 and communication interfiace 118. In accordance 
with the invention, one such downloaded application provides for establishing typed 
permissions as described hereiiL 

The received code may be executed by processor 1 04 as it is received, and/ or stored in 
35 storage device 1 10, or other non-volatile storage for later execution. In this manner, computer 
system 100 may obtain application code in the form of a carrier wave. « 
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FUNCTIONAL OVERVIEW 
As mentioned above, systems that allow execmion of software from remote sources 
present diflScult security problems. The systems that have been developed to address those 
problems are complex, often requiring the use of elaborate permission rules to deal with 
5 principals received from numerous sources. As the security needs of the systems change, the 
permission rules must be updated by someone who understands the complexities of the 
system. 

According to one aspect of the invention, the complexities associated with elaborate 
permission rules and systems are reduced by making use of a powerfiil object-oriented concept 
10 understood by most programmers, known as " inheritance'* , to establish relationships between 
classes of permissions. The general concepts of object orientation, inheritance and classes arc 
described in Appendix L 

As shall be described in greater detail hereafter, a permission super class** is 
established from which subclasses may be created. Objects that belong to subclasses of the 
1 5 permission super class represent permissions, and are therefore referred to as permission 

objects. The permission subclasses inherit the methods and attributes of fte permission super 
class, including a validation method. Each permisnon subclass provides an implementation of 
the vtdidation method. 

When the validation method is invoked for a particular permission object belonging to 
20 a permission subclass, the validation method indicates whether a given permission is 

encompassed by the permission represented by the particular permission object For example, 
die validation method of a permission object POl may be invoked to determine whether die 
permission represented by another permission object P02 is encompassed in the permission 
represented by POl, where both POl and P02 belong to classes that descend from said 
25 permission super class. 

Because the establishment and management of permissions is implemented around the 
class and inheritance mechanism that is familiar to most programmers, permission 
management tends to be simpler and more intuitive. As the security needs of a system 
changes, the typed permission system provided herein allows easy modification to adapt to the 
30 changes, without requiring specialized knowledge of complex security-management 
techniques. 

PERMISSIONS 

As mentioned above, a permission is an authorization by the computer system diat 
allows a principal to perform a particular action or fimction. According to one embodiment of 
35 die invention, permissions can be organized into categories that correlate to categories of 
actions that are performed on computer systems. Each category is characterized by one or 
more attributes shared by all permissions belonging to die category or subcategory. Attributes 
of each category include an action associated with the permission, and can include various. 
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Other attributes that further qualify the action attribute, such as a target attribute. A target is 
any entity, such as a bank account, an adult TV channel, or a computer resource (e.g. files, 
memory, primers, database records), to which an action is directed. 

For example, one common permission category is the file system permission category. 
5 A file system permission has an action attribute and a target attribute. The target is a particular 
file or set of files upon which an action can be perfonmed. The action attribute is an action that 
can be performed on a file, such as " writing" to a file. The target attribute serves to further 
qualify the action by limiting the endties upon which die action can be performed. An 
example of a file system permission is an authorization to "write" (i.e. the action) to a 
10 particular file like ** /anyfile*' (i.e. the target). Note that in die examples provided herein, the 
file(s) and directory in which the file(s) is contained are represented in a form recognized by 
those skilled in the art 

Another example of a permission category is a bank account penxussion for a computer 
application used to manage bank accounts. A bank account permission can have an action 
1 5 attribute, an account attribute, and an amount attribute. An example of a bank account 
pomissicm would be an audiorization to "withdraw** ftom bank account "1233456" an 

amoimt of three dollars. 

Note that permissions categories can fimher comprise subcategories diat arc useful for 
organizing permissions. For example, a subcategory of a bank account permissions can be 
20 pennissions associated with a particular bank. 

IMPLIED PERMISSIONS 
One permission can imply another. When one permission implies another permission, 
ibat one permission is said to encompass die otiier permission. For example, a permission to 
write to a directory, sudi ''ciT , can imply a pcrmbsion to write to any file in die directory, 
25 such as " cidiisfile" . Furthermore, an attribute of a permission can imply an attribute of 
anodier permission. For example, in some implementations, die action attribute of a 
permission to " write" implies an action attribute of a permission to " read" . An amount 
attribute of a permission to wididraw ducc hundred dollars implies another attribute of a 
permission to withdraw two hundred dollars. 
30 Usually, a permission encompasses anodier permission when all die permission 

attributes of one permissioii imply all die corresponding permission attributes of anodier 
permission. For example, a permission to "write" to file"d:/somefilc" impUes a permission 
to " read" from file " di/somcfile" because a write" impUes a read'' . However, a permission 
to "write" to file "d^somefile" does not imply a permission to "read" fiom file 
35 " d:/otherfile" because ** d-iscHnefile" does not imply " d:/otherfiIe" 

REPRESENTING PERMISSIONS WITH CLASSES AND OBJECTS 
Using die techniques described herein, classes arc used to represent categories of and 
subcategories of permissions, and objects of dwse classes are used to represent die particular 
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permissions in a category or subcategory of pennissions. A pamission represented by a class 
is herein referred to as a typed permission. Classes used to represent categories of pennissions 
are herein referred to as permission classes. Objects which belong to a permission class arc 
herein referred to as permission objects. Furthermore, the fields of a permission class are used 
5 to represent the attributes of the category or subcategory of permissions represented by the 
permission class. 

For example, a FilePermission permission class can represent the category of file 
system permissions. The FUePermission class can have an action field which corresponds to 
the action attribute, and a target field which corresponds to the target attribute. 
10 Each permission object contains fields with values corresponding to attributes of a 

particular permission represented by the permission object For example, a given object 
belonging to the FilePermission class can have an action field with a value representing a 
" write" action, and a target field with a value representing the directory " diT . In this 
example, the given object represents a permission to "write" to directory "d:/" . 
15 Note that each permission object is an instance of a permission class. Likewise, a 

permission objett and the permission it represents axe said to represent an instance of a 
permission category or subcategory. 

THE PERMISSION SUPER CLASS 
20 Because all pennissions share some common attributes, it is usefiil and efficient to 

represent all categories of pennissions with one class that is a super class of aU permission 
classes. The super class for all permission classes is herein referred to as the pemiission super 
class. Each permission class is a subclass of the permission super class. 

TT» permission super class contains fields which represent attributes common to all 
25 permissions. One such field is an action field, which represents die action attribute common to 
all pennissions. 

In addition to sharing attributes, the pennission super dass establishes a set of 
common methods that are useful for and inherited by all pemiission objects, such as a 
get.action method. Tbe common action method returns a value representing the actton field. 
30 An implementation for the get.action method may be provided in the pemiission super class. 
According to one embodiment, the implementation for the get.acrion method smiply reuims 
the value of die action field. 

THE VALIDATION METHOD 
In addition to implementing a set of common methods shared by pennission 
35 subclasses, the pennission super class also establishes the interfiu* to methods 

supported by every object but whose implementation depends on the parti<3ilar pennission 
class of the object * ' 
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An example of such method is a validadon method that indicates whcdier a pennission 
represented by one pcimission object encompasses another pennission represented by another 
permission object. As noted earlier, a pennission typically encompasses another pennission 
when each attribute of the one permission implies the corresponding attribtite of the other 

5 pennission. Because attributes of one permission category may dififer fiom attributes of 
another pennission category, the pennission classes which represent pennission categories 
may contain different sets of fields, dius necessitating a different implementation of the 
validation method for some of the pennission classes. Furthennore, the niles that govern 
whether a particular attribute implies another attribute may vary from one pennission category 

10 to another. Hence, the implementation required for die validadon medwds which cany out die 
rules can vary. 

For example, the FilePennission pennission class has an action field and a target field. 
The target field could represem a file or a set of files (e.g.. "di/somedirectory/somefile"). A 
pennission class representing a bank account, AccountPennission. can have an action field, an 
15 account field, and a maximum amount field. The two pennission classes. FilePennission and 
AccountPennission have a dif&rem number attributes and different kinds of attributes. 

TTie niles goveming wheUier one attribute of one pennission impUes a conesponding 
attribute of anodier pennission may differ from pennission class to pennission class as weU. 
Specifically, die implementation of detennining whedier a pennission for one set of files 
20 implies a pennission for anodier set of files differs significanUy from an implementation diat 
detennines whedier a pennission for one maximum amount impUes anodier amount It is 
wordi noting tiiat pennissions of differem pennission classes usually cannot encompass each 

other. 

Aldiough die implementation of some mediods supported by all pennission objects can 
25 vary from one pennission class to anodier, die pennission super class may be used to (msure 
diat die result type of a mediod and its parameters can remain constant across aU pennission 
classes. Defining die interface to mediod in die pennission super class widiout providing die 
implementation for die mediod establishes an interfiice diat can be reUed upon by all objects 
and object implementers (i.e. programmers) when interacting widi pennission objects. 
30 Ti««»skiUed in die ait wfll recognize various techniques can be used to provide such 

an inteifece. One mediod would be to provide a super class widi an abstract mediod diat 
would be implemented by subclasses of die super class. Anodier mediod would be to provide 
a pennission super class diat defines a default implementation tiiat subclasses can ovcmde. A 
defimlt implementation can be. for example, to always return a value indicating diat one 
35 pennission is not encompassed by anodier pennission. Anod« mediod uses Java Intcrfiices 
instead of abstract classes. 
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CREATING TYPED PERMISSIONS 
Techniques for creating and using typed permissions shall now be described with 
reference to the permission classes shown in Fig. 2. The classes shown in Fig. 2 arc used to 
create objects that represent permissions to manage access to a television (TV). For purposes 
of illustration, assume that permissions associated with accessing a TV have an action 
attribute and a target attribute. The action attribute can either be to watch** , " enable"* , or 
disenable** a channel. The target attribute represents a particular chaimeL 

Several examples of permission objects representing several TV permissions are 
shown in Fig. 2. Permission Object 282 represents a permission to disenable'* "channel S", 
and permission objects 286 represents a permission to "watch** "channel 5** . Permission 
object 282 and permission object 286 are objects belonging to the subclass TV subclass 230. 
TV subclass 230 is a subclass of permission super class 210. 

Referring to Figure 3, in step 3 10 the attributes of the permission super class are 
established. In this example, an action field 222 is established for permission super class 210. 
Tbe action field 222 is a string data type. The action field 222 represents the piennission 
attribute of any category of permission. 

In step 320, a validation method and other methods for a permission object arc 
established. In this example, an abstract vaUdation method 224 is provided. The validation 
method accepts as its first parameter an object reference of the data type (i.e. class) Permission 
class. Thus an object reference rcfenring to an objea belonging to any permission class is an 
acceptable parameter. The data type of the value returned by the method is Boolean. The 
Boolean value letumed by the validation method indicates whether the permission represented 
by the permission object referred to by the object reference is encompassed by the permission 
represented by the permission object whose validation method is invoked. For example, 
assume X and Y are permission objects. The method invocation X.Validation( Y ) will return 
True if the permission represented by Y is encompassed in the permission represented by X, 
and False if the permission represented by Y is not encompassed in the permission represented 
byX. 

According to one embodiment, no implementation of the abstract validation method 
224 is provided in permission super class 210. The implementation is left to the subclasses of 
permission super class 2 1 0. 

A get^action method is also provided in the permission super class 210. The get_action 
method returns a string value representing the value contained in the action field 222. An 
implementation is provided for the get^action method. The implementation merely returns the 
value of die action field as the return value of the get_action method. 

Those skilled in the art will recognize diat odm mediods and attributes c^ 
provided. Only some of these methods and attributes have been illustrated in prder to avoid 
unnecessarily obscuring the techniques described herein. 
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An example code implementation of a penmssion super class 210 is illustrated below. 
Although the code example may resemble the JAVA programming language by Sun 
Microsystems Inc., the example is merely for illustrative purposes and is not meant to be 
representative of an actual code implementatioiL 
abstract class Permission { 

protected String action; 

abstract Boolean validate(Permission p); 



) 

ESTABLISHING PERMISSION SUBCLASSES 
In step 330, an implementation of the abstract validation method 224 is provided in the 
form of a vaUdation implementation 242 of a subclass of Pciinission super class 210. In this 
exanq)le, a TV subclass 230 is defined as a subclass of Permission super class 210. The 
implementation 242 of abstract validation method 224 includes code which, when executed, 
imdally determines whether the object reference parameter refers to a permission object of 
same class as that of the permission object whose validation method is being invoked. 

When the classes of permission objects differ, one permission represented by a 
permission object does NOT encompass the permission represented by the other permission 
object because a permission of one categi»y does not encompass a pennis^on of another 
category. For example, a TV permission does not encompass a file system pcrmisaon. 

Next, the code in the implementation 242 ensures that each attribute of the permission 
represented by the object reference is impUed by each attribute of the permission represented 
by the object whose vaUdation method is invoked. For example, if the action field and the 
target field of the permission object referred to by the object reference are identical to tiie 
action field and target field of the pcmiission object whose validation method is invoked, dicn 
the validation method returns a true Boolean value. 

In step 340. attributes and other methods of the TV subclass 230 are estabUshed. The 
other methods may include both new methods, and new implementations that override the 
implementations of inherited methods. In this example, a target field representing the target 
attribute of a TV permission is defined. A get_target method 246 is also provided. H» 
get_target method simply rcwms a string value representing the channel attribute of the 
permission represented by the TV permission object 

An example code implementation of the TV subclass 230 is iUustrated below. 
Although the code example may resemble die JAVA programming language by Sun 
Microsystems Inc., the example is merely for illustrative purposes and is not ineant to be 
representative of an actual code implementation. 
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class TV extends Permission { 
{Hotected String target; 

public string get_targetO { 
return target; 

} 

TV(String a. String t){ 
action = a; 
target =t; 

) 

public Boolean validate(Pennission p) { 
if(p inslanceofTV = false) 

return false; 
TVreqPenn= (TV)p; 
if (rcqPerm.get_actionO != action) 

return false; 
if (reqPernLgetjargctO '= target) 

return &Ise; 
return true 

} 



} 



In step 350, the petmission super class 210 and subclasses of the permission super 
class 210 are compiled and placed in a software library. Those skilled in the art are familiar 
with software tools arid techniques used to compUe the classes described above and to place 
them in software libraries. An example of such a tool is the Java Development Kit by Sun 
Microsystems Inc. 

TTiose skilled in the art wiU recognize that, in addition to the ones Ulustrated above, 
other attributes and methods are possible in permission subclasses. Only some these attributes 
and methods have been iUustrated in order to avoid unnecessarUy obscuring the techniques 
described herein. 

Furthermore, techniques described above are not limited to permissipn classes whose 
parent class is the permission super class 210. The techniques are applicable to subclasses of 
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other permission classes which themselves are descendants of the permission super class. For 
example, it may be useful to provide a TV permission class, and then a subclass of the TV 
permission class that corresponds to a particular cable company. 

PERMISSIONCOLLECTION OBJECTS 
5 In an embodiment of the invention, a PermissionCollection super class is provided to 

allow security administrators to easily manage sets of permissions. A PermissionCollection 
class is used to create objects that each contain a set of zero or more permission objects. An 
object that is a subclass of the PermissionCollection super class is herein referred to as a 
PermissionCollection object A PennissionCollection object manages a set of permission 
10 objects contained by the PermissionCollection object A homogenous PermissionCollection 
object may only contain permission objects belonging to the same class, a heterogeneous 
PermissionCollection object may contain permission objects belonging to different classes. 

The PermissionCollection super class defines several methods. One method returns an 
enumeration of the pemussion objects contained in the PermissionCollection object 
15 Another method, add j>emtiission, adds a permission object to the set of pemission 

objects contained in the PermissionCollection object The add_pennission method has a 
parameter of the type Permission. In the case of a homogenous PennissionCIass object, for 
example, the method to add a pemiission object does not add a permission object if it is not of 
the same type (i.e. class) as any other pennission object already contained in the 
20 PermissionCollection object The method returns a Boolean flag indicating whether or not a 
permission object was added. 

A group validation method is another method defined by the PennissionCollection 
super class. The method accepts one parameter of the data type Permission. The method 
indicates whether or not any of the permissions represented by the permission objects 
25 contained in a PermissionCollection object encompass the perawssion represented by the 

permission object specified by the parameter. The mcdiod processes each permission object by 
invoking each pennission objects validation method until either (1) Uie validation metiiods of 
all permission objects in the set have returned False or (2) a validation metiiod for a 
permission object in die set returns True. 
30 A PermissionCollection object used to manage a set of permission objects can be 

created direcUy for the PermissionCollection super class, or from a subclass of the 
PermissionCollection class. A subclass of tiie PermissionCollection super class can contain 
methods that provide functionality specific to a particular pennission class. 

For example, a PermissionCollection object for FilePermissions can provide an 
35 IsTargctfmplicd method. The IsTargetlmplied method indicates whether or not a particular 
target is implied by anotiier target For example, the mcAod could syntactically determine 
whether "/sys/sysfile" is impUed by "/sys/*-. i 
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SECURITY USING "FINAL" DESIGNATION 
Many programming languages provide the keyword final"" to designate that 
something cannot be overridden. For example, if a class X is defined as final, then the 
compiler will generate an error if subsequent code attempts to define a subclass of class X. 
Alternatively, a class that is not final may have one or more methods that arc declared to be 
final. For example, class Y may not be final, but class Y may define five methods, three of 
which are declared to be final. Under these circumstances, the compiler will allow subsequent 
code to define a subclass of class Y, but the subclass will inherit the three methods as is. The 
subclass will not be able to override the three inherited methods by defining alternative 
implementations for the methods. 

According to one embodiment of the invention, suf^rt for the final^ kejrword is 
combined with permission classes to implement strong but flexible security mechanisms. For 
example, assume that a first developer defines a FilePennission subclass of the Permission 
super class. Assume fiirther that the Validation method for the FilePermission class returns 
True when the invoked permission is " write c:\^** and the input permission is " write 
c:\sys\config.txt" . The first developer may want to distribute the FilePermission class in a 
runtime library for use by other developers. 

If a user of the library is allowed to create a subclass of the FilePermission class and 
override the validation method, fhe security policy programmed into the FilePermission logic 
may be conqiromised. For example, security would be compromised if the validate mediod of 
the FilePennission class is overridden with logic that returns True when the invoked 
petmission is ** write c:\*** and the input permission is write dA*** . 

For the first developer, it may be critical for the applications developed by the users of 
the runtime library to reflect the same degree of security as is programmed into the 
FilePennission logic. To prevent security loopholes, the first developer may declare the 
FilePennission class to be final. As a result, any user of the library would be unable to use 
any security policies with respect to file access other than the security policies embodied in the 
original FilePermission class. 

While declaring the FilePermission class to be final will prevent security breaches, it 
limits the flexibility of the library. For example, users of the library should be aUowcd to 
inq)lement security policies with respect to file access that are more restrictive than the 
FilePermission class policies. Thus, a user of the library may decide to implement a system 
that requires exact directory matches. In such a system " write c:\*- would encompass " write 
c:\heIIo.txt^ but would not encompass ''write c:\sys\joe.txr . 

To allow library users to enforce more restrictive security poUdes, the FilePoxnission 
class may be non-final, >;^*ile all mefltods of the class but one arc declared ^ final. The non- 
final method, which may be called the AdditionalCheck method, may be overridden by the 
library user. The Validation Method, which is 5jMd, may call the AdditionalCheck method as 
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a final step to dctennine whether a particular permission is encompassed by the invoked 
permission object. The Boolean value generated by the Validation Method logic are 
combined in a logical AND operation with the Boolean value generated by the 
AdditionalCheck method to produce the Boolean value that is ultimately remroed by the 
S Validation Method. 

Because the value returned by the Validation Method is always false if the validation 
method logic is false, the security policy employed by the application developed by a library 
user is at least as restrictive as those embodied in the original FilePermission class logic. 
However, because the library user is allowed to override the AdditionalCheck method, the 
10 library user has the flexibility to implement sectirity rules that are more restrictive than the 
original FilePennission class logic. 

EXEMPLARY SECURITY MECHANISM 
An exemplary security mechanism illustrating one use of typed permissions is shown 
in Figure 4. Referring to Fig. 4, the exemplary security mechanism includes a policy file 444, 
15 a policy object 440, a domain mapper object 448, an access controller 480, and one or more 
protection domains 482. The security mechanism is implemented using a code executor 410. 

Code executor 410 executes code which code executor 410 receives from code stream 
420. One example of a code executor is a Java virtual machine. A Java virtual machine 
interprets code called byte code. Byte code is code generated by a Java compiler from source 
20 files contuning text. The Java virtual machine is described in detail in Tun Lindholm & Frank 
VMln Thi. Java Virtual Machine Specification (1996). 

For the purposes of explanation, it shall be assumed that code from code stream 420 is 
object oriented software. Consequently, the code is in the fonn of methods associated with 
objects that belong to classes. One or more class definitions for a class are contained in code 
25 from code stream 420. The fields and methods of the objects belonging to a class are defined 
by a class definition. These class definitions are used by code executor 410 to create objects 
which are instances of the classes defined by the class definitions. 

These class definitions arc generated from source code written by a programmer. For 
example, a programmer using a Java Development Kit enters source code that conforms to the 
30 Java programming language into a source file. The source code embodies class definitions and 
other instructions which arc used to generate byte code which controls the execution of a code 
executor (i.e. a Java virtual machine). Techniques for defining classes and generating code 
executed by a code executor, such as a Java virtual machine, arc well known to those skilled in 
the art 

35 Each class defined by a class definition from code stream 420 is associated with a class 

name 438 and a code source 436. Code executor 410 maintains an association between a class 
and its class name and code source. The code source represents a source of code from which is 
code received. A "source of code" is an entity from which computer instructions arc received. 
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Examples of sources of code include a file or persistent object stored on a data server 
connected over a network, a FLASH^EPROM reader that reads instructions stored on a 
FLASH^EPROM, or a set of system libraries. 

The code source may be a composite record containing a uniform resource locator 
("URL") 434 and set of public cryptographic keys 432. A URL identifies a particular source. 
The URL is a string used to uniquely identify any server connected to the world wide web. A 
URL may also be used to designate sources local to computer system 100. Typically, the URL 
includes the designation of the file and directory of the file that is the source of the code 
stream that a server is providing. 

A public cryptographic key, herein referred to as a key, is used to validate the digital 
signature which may be included in a file used to transport related code and data. Public 
cryptographic keys and digital signatures are described in Schneier, Applied Crvptographv. 
(1996). The keys may be contained in the file» may be contained in a database associating keys 
with sotirces (c.g. URLs), or be accessible using other possible alternative techniques. 

A class may be associated with the digital signature associated with the file used to 
transport code defining the class, or the class definition of the class may be specifically 
associated with a digital signature. A class that is associated with a valid digital signature is 
referred to as being signed. Valid digital signatures are digital signatures that can be verified 
by known keys stored in a database. If a class is associated wiA a digital signature which can 
not be verified, or the class is not associated with any digital signature, the class is referred to 
as being unsigned. Unsigned chisscs may be associated with a dcfiodt key. A key may be 
associated wifli a name, which may be used to look up the key in the database. 

While one code source format has been described as including data indicating a 
cryptographic key and URL, alternate formats are possible. Other information indicating the 
source of die code, or combinations thereof, may be used to represent code sources. TTietcfore, 
it is understood that the present invention, is not limited to any particular format for a code 
source. 

TRUSTED AND UNTRUSTED SOURCES 
The source of code stream 420 may be from zero or more untrosted sources 424 or 
zero or more trusted sources 428. Untrusted sources 424 and trusted sources 428 may be file 
servers, including file servers that are part of the World Wide Web network of servers 
connected to the Internet. An untrusted source is typically not under the direct control of the 
operators of computer system 100. Code from untrusted sources is herein referred to as 
untrusted code. 

Because untrusted code is considered to pose a high security risk, the set of computer 
resources that untrusted code may access is usually restricted to those which do not pose 
security threats. Code from a misted source is code usually developed by trus^ developers. 
Tnisted code is considered to be reliable and pose much less security risk than remote code. 
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Software code which is loaded over the networic fixjm a remote source and 
immediately executed is herein referred to as remote code. Tyirically, a remote source is a 
computer system of another separate organization or individual. The remote source is often 
connected to the Internet 

5 Nomially untnisted code is remote code. However, code from sources local to 

cranputer system 100 may pose a high security risk. Code from such local sources may be 
deemed to be untnisted code from an untrusted source. Likewise, code from a particular 
remote source may be considered to be reliable and to pose relatively little risk, and thus may 
be deemed to be trusted code from a trusted resource. 

10 According to one embodiment of the invention, typed permissions are used in 

conjunction with protection domains to implement security policies that allow misted code to 
access more lesowces than untrusted code. A security policy thus established determines 
what acticHis code executor 410 will allow the code within code stream 420 to perform. The 
use of typed permissions and protection domains allows policies that go beyond a simple 

15 trusted/untrusted dichotomy by allowing relatively complex permission groupings and 
relationships. 

Protection domains and policies that may be used in conjunction with typed 
permissions shall now be described in greater detail widi continued reference to Figure 4. 

20 PROTECTION DOMAINS AND POLICIES 

Protection domains ate used to enforce security witMn computer systems. A protection 
domain is a set of permissions granted to one or more principals. As described above, 
permissions arc represented by permission objects. Lilaaries, usually located in trasted 
sources, contain class definitions for the permission super class 210 and permission classes. 
25 TypicaUy these libraries are accessible by code being executed by code executor 410. 

The correlation between permissions and principals constitutes the policy of Ae 
system. Figure 4 illustrates an exemplary poUcy implemented through use of a policy file 444. 
A piotection donuin in this exemplary poUcy is defined as the set of peraiissions granted to 
the objects associated with a particular code source. The poUcy of the system is represented by 
30 one or more files containing instructions. The instructions map code sources to permission 
objects which represent the permissions authorized for the protections domain corresponding 
to the code source. Each instruction establishes a mapping between a particular code source 
and a particular permission object An instruction represents one authorized permission fot the 
objects belonging to tiie classes associated with the code source in the instruction. 
35 The format of a typical instruction in die exemplary policy file 444 is: 

'e*peimission''> <URL> <key name> <permission class name> <action> <target> 
The <URL> and die key corresponding to die <key name> represent a code source. The key 
name is associated vridi a key. The key and corresponding key name are swred togedier in a 
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database. The key name can be used to find the key in the database. The <pennission class 
name> represents data identifying a permission class. The <action> and <target> represents 
data used to initialize (i.e. using an permission object constrxictor) the action and target fields 
in a permission object belonging to the identified permission class. Instruction S20»l in Fig. S, 
for example, is an authorization of a permission to write to any file in ""/mpJ^"" by any object 
of the class associated with code source " file://somesource** - * somekey" (i.e. URL*key 
name). 

Referring to Fig. 4, in order to efScienily and conveniently implement the policy and 
establish protection domains, policy object 440, domain mapper object 448, and one or more 
protection domain objects 482 arc provided. Policy object 440 provides a mapping of code 
source to permission objects based on the policy file. Policy object 440 is inidalized when 
code executor 410 is initialized The policy object 440 parses the policy file 444. For each 
instruction, a pennission object of the permission class designated in the instruction is created 
using the values of the action and target attributes that are designated in the instruction. 
Finally, the pennission object is mapped to the code source designated in the instruction. 

While one method for representing the security policy of computer system has been 
described, other methods are possible. For example, a policy data base may contain fields that 
represent the code source, permission class, action and target Therefore, it is understood that 
the tedmiques described herein are not limited to any specific method of storing a 
represenlatioQ of security policy of a computer system. 

Note that even though the instruction illustrated above contains data used to inidalize 
two fields, a pcraiission object may in feet have more or less than two fields to initialize. For 
example, a bank account permission may have an action, accotint, and maximum amount 
attribute. When a bank accoimt pemiission object is initialized, the values in instruction 
corresponding to action, account, and maximum amount attributes would be used to initialize 
the permission object 

The domain mapper object 448 contains a nuking between classes and protection 
domains objects. Protection domain objects 482 contain a set of permissions. Protection 
domain objects are associated with the pennission objects they contain, and with the classes to 
which a protection domain object is mapped to by domain mapper object 448. 

Protection domain objects 482 arc created when new classes are received by code 
executor 410. When a new class is received, domain mapper 448 determines whether a 
protection domain is already associated with the code source. The domain mapper maintains 
data indicating which protection domains have been created and the code sources associated 
with the protection domains. If a protection domain is already associated with the code source, 
the domain mapper adds a mapping of the new class and protection domain to a mapping of 
classes and pn)tection doniains rnaintained by the doniain rnapper 448. , . 
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If a protection domain object is not associated with the code source of the new class, a 
new protection domain object is created and populated with permissions. The protection 
domain is populated with those permission that are mapped to the code source of the new class 
based on the mapping of code sources to permissions in the policy object Finally, the domain 
5 mapper adds a mapping of the new class and protection domain to the mapping of classes and 
protection domains as previously described. 

In other embodiments of the invention, instead of storing the mapping of classes to 
protection domains in a domain mapper object, the mapping is stored as static fields in the 
protection domain class. The protection domain class is the class to which protection domain 
10 objects belong. There is only one instance of a static field for a class no matter how many 
objects belong to the class. The data indicating which protection domains have been created 
and the code sources associated with the protection domains is stored in static fields of the 
protection domain class. Alternatively, a mapping between a class and protection domains 
associated with the class is stored as static fields in the class. 
IS Staiic methods axe used to access and update the static data mentioned above. Static 

methods are invoked on bdialf of the entire class, and may be invoked without referencing a 
specific object 

EXEMPLARY ACCESS CONTROL 
An exemplary method using access controUer 480 accort&ng to steps shown in Fig. 7 
20 illustrates a use of permission objects. The calling stack, protection domains, and permission 
objects shown in Fig. 6 are used as an example illustrating the performance of the steps shown 
in Fig. 7. 

A code executor, such as a Java virtual machine, maintains for each thread or process a 
call stack of the object methods invoked by the thread or process. The call stack reflects the 
25 calling hierarchy between the methods that have been invoked but not yet completed by the 
thread or process. The call stack includes information identifying the objects with methods on 
the call stadL For example, assume that a thread executes ajc (where "a" is an object and "x" 
is a method associated vrith object "a"). Assume that aa invokes b.y which invokes cz. 
While cz is executing* Ac call stack will contain data identifying a jc, b.y, and cz. At this 
30 point, call stack 610, in Fig. 6, represents the caUing hierarchy of the methods invoked by the 
thread but have not yet been completed by the thread. When the thread finishes execution of 
cz , the data identifying cz will be removed fiom call stack 610. 

Note that each object represented by the call stack is associated with a protection 
domain. Object a is associated with {notection domain 1 and object b and object c are 
35 associated with protection domain J. Each protection domain object shown in Fig. 6 is 

associated wiA permission objects. The association between the objects, protection domain 
objects, and the permission objects is based on the a domain mapper object 448, policy object 
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440, policy file 444, and constitutes the security policy with respect to the objects shown in 
Fig. 6. 

Assume that a thread invokes a.x, b.y, and ca. in the manner described so that call 
stack 610 is as it appears in Fig. 6. Referring to Fig. 7, assume that b.y requests an action, the 
5 action being to "disenable" "channel-^. Typically, a request is in the form of an attempt to 
invoke a particular method that perfonns a particular operation. In this example, the particular 
request is made by object b. In other words, a method associated with object b invoked a 
method that may perform the particular actioru 

Typically, access to a resource by code being executed by a code executor can only be 
10 made by invoking a resource manager. A resource manager is an object assigned the 

responsibility of managing access to its respective resource. In this example, object a is the 
resource manager. It is the resource manager, objea a, that receives the request from object b. 

In step 754, the resource manager creates a permission object based on the permission 
required to perform the requested action. In this example, the permission required to perform 
1 5 this action is to " disenable" " charmel-5'* . A permission object belonging to TV subclass 230 
is created based on the permission required, using " disenable" and ** channel-5" as values for 
the action and target fields respectively. The permission required to perform a requested action 
is herein referred to as a required permission. The permisston object created on the basis of the 
permission required is herein referred to as the required permission object Control passes to 
20 step 760. 

DETERMINING WHETHER AN ACTION IS AUTHORIZED 

In step 754, a request is received for a determination of whether the action is 

authorized. The determination is based on the permission required to perform the action. In 

this example, the resource manager invokes an access controller to determine whether the 
25 permission reqtiired is authorized for the entity requesting access. The access controller 

receives the request and a required permission object which was transmitted by the resource 

manager. 

In step 754, the validation methods of one or more permission objects is invoked in 
order to determine whether an action is authorized based on the permission required. An 

30 action is autisorized if every protection domain object associated with an object requesting a 
determination of whether an action is authorized contains a permission represented by a 
permission object that encompasses the required permission for the actiort 

The protection domains associated with an object requesting the determination are the 
protection domain objects associated with each object represented by die calling hierarchy 

35 when the request was made. Any protection domain object associated with an object 
requesting a determination of whether an action is authorized is herein referred to as 
associated protection domain object. Finding the protection domain objects associated witii a 
given object begins by determining the class of a given object A code executor, such as a Jav 
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virtual machine, provides that each object incorporate a method which returns the class of an 
object Next, the method of the class/domain mapper that returns the protection domain object 
associated with a class is invoked. 

For each of the associated protection domain objects, the validation methods of each 

5 permission object contained in the protection domain object are invoked passing in the 

permission required object as a parameter. The validation methods of each permission object 
contained in the associated protection domain are invoked until a permission object indicates 
that the permission it represents encompasses the required permission. If none of the 
permission objects in a protection domain indicates that the permission the permission object 

10 encompasses the required permission, then die remainder of die associated protection domain 
objects are ignored. 

In this example, the access controller first determines die protection domain associated 
with the first object represented on call stack 610, ^ch is object a. The protection domain 
associated with object a is protection domain 1. The validation metiiod ofthe first permission 
15 object, permission object 282 (in Fig. 6), is invoked, passing in die required permission object 
as a parameter. As mentioned earlier, die required permission represented by die required 
permission object is a permission to " disenable^ " channel-5'' . When die validation mcdiod of 
die first permission object is invoked die validation method indicates diat the required 
permission is not encompassed. Next, die validation method of permission object 286 (in Fig. 
20 6) is invoked. The invocation of die validation mediod of permission object 286 indicates diat 
die required permission is encompassed. 

The access controller dien invokes die validation methods of die permission objects in 
die next protection domain object, protection domain object J, in die manner described. Each 
invocation of die validation mctiiods of permission object 622 and permission object 626 
25 indicates that the required permission is not encompassed. 

At step 764, a determination is made of whedier die action requested was atrthorized. If 
every associated protection domain contains a permission object diat represents a permission 
encompassing die required pemussion, dien die requested action is audiorized. When die 
requested action is audiorized, control passes to step 768, where die action is performed before 
30 execution of die steps ceases. In diis example, because not every protection domain object 
contained a permission encompassing die required permission, performance of die steps ends. 
The requested action is not executed 

Typed permissions facUitate die establishment of new permissions. When a new category of 
permissions is desired, a new subclass is created. The particular rules or poUcy diat govern 
35 whcdier die permissions granted a principal arc encompassed by permission in die new 
category are implemented in die vaUdation mediod of die new subclass representing 
permissions m the new subclass. ^ 
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Providing an abstract method for the determining whether a particular permission is 
encompassed by another establishes an standard inter&ce for detemuning Aether a particular 
permission represented by an permission object is encompassed by the permission represented 
by another permission object. The interface can be used and relied upon by any security 

S mechanism. The security mechanisms that use the standard inter&ce automatically efiectuate 
rules or particular policy of a new permission category represented by the new subclass. 

In the foregoing specification, the invention has been described with reference to 
specific embodiments thereof. It will, however, be evident that various modifications and 
changes may be made thereto without departing from the broader spirit and scope of the 

10 inventioa The specification and drawings are, accordingly, to be regarded in an illustrative 
rather than a restrictive sense. 
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APPENDIX I 
OBJECT ORIENTATION AND INHERITANCE 
In object oriented programming, the world is modeled in terms of objects. An object is 
a record combined with the procedures and functions that manipulate it. All objects of a class 
5 have the same fields* and are manipulated by the same procedures and functions ("methods"). 
An object is said to be an "instance" of the class to which it belongs. 

Sometimes an application requires the use of classes that arc similar, but not identical. 
For example, the classes used to model both dolphins and dogs might include the fields for the 
nose, mouth, length and age. However, the dog class may require a hair color field, while the 
10 dolphin class requires a fin size field. 

To facilitate programming in situations in which an application requires multiple 
similar fields, object oriented programinirig supports "inheritance'*. Without inheritance, a 
programmer would have to write one set of code for the dog class, and a second set of code for 
the dolphin class. The code implementing the fields and methods coounon to object classes 
1 5 would appear redundantly in both classes. Duplicating code in this manner is very inefficient, 
especially when the number of common fields and methods is much greater than the number 
of unique fields. Further, code duplication between classes complicates the process of 
revising the code, since changes to a coEwnon fields will have to be duplicated at muldple 
places in the code in order to wiMntain consistency between all classes that have the field. 
20 Inheritance allows a hierarchy to be established between classes. Thefieldsand 

mediods of a class automatically become fields and methods of the classes that are based upon 
the given class in the hierarchy. For example, an "animal" class may be defined to have nose, 
mouth, length and age fields, with associated methods. To add these fields and methods to the 
dolphin and dog classes, a programmer can specify that the dolphin and dog classes "inherit" 
25 the animal class. A class which inherits its fields and methods from another class is said to be 
a subclass of the other class. The other class, the class fiom which the subclass inherited its 
fields and methods, is said to be a parent class. In this example, the dolphin and dog classes 
are "subclasses** of the animal class, and die animal class is a parent class of the dog and 
dolphin classes. 

30 The code for the inherited fields and methods is located in the parent class and is not 

duplicated \n any subclasses. The subclasses only contain the code for fields and mediods that 
supplement or override the fields and methods of the parent class. Consequently, aU revisions 
to a parent class automatically apply to all subclasses. For example, if the field "age" is 
defined as an integer in the animal class and is not ovenidden m the dog and dolphin classes, 

35 then the dog and dolphin classes will include an integer to store an age value. If the animal 
class is revised so that "age" is defined as a real number, then the dog and dolphin classes will 
automatically include a real number to store an age value. ^ 
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Note a third or greater level in a hierarchy of a classes can be established. A given 
class can inherit fields and methods of a class that is itself of a subclass of another class. A 
class above a particular class in a hierarchy is said be a super class to that particular class. 
Thus a parent class is a super class to its subclasses, and a super class to any class inheriting 
5 from a subclass of that parent class. 

MEraODS AND ABSTRACT CLASSES 
The methods of classes accept zero or more parameters. A class constructor, which is 
similar to a method, is used to initialize the fields of an object when objects belonging to that 
class are created. 

10 The code containing the instructions to perform the operations associated with a 

method is said to be an implementation of the method. A method may be defined for a class 
witfiout an implementation. A method with no implementation is said to be an abstract 
method; a class which contains an abstract method is said to be an abstract class. 

Abstract classes are useful for establishing a common inter&ce for the subclasses of 
1 5 abstract classes. The interface for an abstract method establishes the name of the niethod, the 
data type returned by a method and the data type of the method*s parameters. The subclasses 
of an abstract class is responsible for providing the implementation of the abstract method. 

For example, assume that it is desired that all objects provide an interfiacc which 
includes a method that indicates the number of legs an animal has. An abstract class, named 
20 animal, with an abstract method called get Jegs that renims an integer representing the 

number of lep can be defined. Every subclass of the animal class would be responsible for 
providing code which implements the get Jegs method for the particular type of animal 
represented by the subclass. For example, a cow subclass would provide a specific 
unplementation for get Jegs that returned the integer four when the get Jegs method of a cow 
25 object was invoked. 

The fields and mcttiods of a class arc defined by a class definition in software. Class 
definitions contained in software are typically created from source code usually received from 
a programmer. The source code is compiled into the code which can be executed by computer 
system 100. For example, a programmer usmg a Java Development Kit enters source code in 
30 the Java programining language into a source file. The source code embodies cla^ 

and other instructions which are used to generate byte code which control the execution of a 
Java code executor, a virtual machine. The JAV A^ virtual machine is described in detail in 
"The JAVA™ Virtual Machine Specification,'' by Tim Lindholm and Frank Yellin (Sun 
Microsystems, Inc.: Addison-Wesley Publishing Co.). The JAVA^ programming language h 
35 described in detail in "The JAVA™ Language Specification," by James Ctosling, Bill Joy and 
Guy Steele (Sun Microsystems, Inc.: Addison-Wesley Publishing Co.), and related texts in 
the JAVA™ Series published by Addison- Wesley. , 
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CLAIMS 
What is claimed is: 

1 . A method for providing security, the method comprising the steps of: 
establishing a permission class; 

5 wherein each permission object that is a member of said pemiission class represents at 

least one permission to perform an action; 
wherein said permission class includes a validation method; 
wherein said validation method, when invoked for a particular pemiission object 

belonging to said pemiission class, indicates whether a specified permission is 
10 encompassed by a pemiission represented by the particular permission object 

2. The method of Claim 1 , wherein: 

the step of establishing a permission class includes establishing a pcraussion subclass 

that is a descendant of a permission super class; 
the permission super class defines an interface of said validation method. 

1 5 3. The method of Claim 2. further including the steps of: 

obtaining a first pemiission object, wherein said first pcmoission object belongs to said 
permission subclass; 

obtaining a second object, wherein said second object belongs to a descendent class of 
the permission super class; and 
20 determining whether a first permission represented by said first pemiission object 

encompasses a second permission represented by said second object by 
invoking a validation method associated with said first permission object 

4. The method of Claim 3, wherein the step of obtaining a second object includes 
obtaining a second object that belongs to said permission subclass. 

25 5. The method of Claim 3, wherein the step of obtaining a second object includes 

obtaining a second object that belongs to a class that is different ftom said permission 
subclass. 

6. The method of Claim 5, wherein: 

the method further includes the step of receiving a request to perform a particular 
30 action; and 

the step of obtaining said second object includes die step of obtaining said second 
object based on said request to perform said particular action. 

7. The method of Claim 6, wherein the step of deteraiining whether said first pemiission 
represented by said first permission object encompasses said second pemiission 
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represented by said second object includes sending to the validation method of said 
first object data that identifies the second object 

The method of Claim 4, further including the steps of: 

obtaining a first permission object, wherein said first permission object belongs to said 
permission subclass, wherein said first permission object specifies a first action 
and a first target; 

obtaining a second object, wherein said second object belongs to a desccndent class of 
the permission super class, wherein said second object specifies a second action 
and a second target; and 
detenxumng whether a first permission represented by said first permission object 
encompasses a second permission represented by said second object by 
determining whether said first action encompasses said second action and 
determining whether said first target encompasses said second target. 

The method of Claim 3, further including the steps of obtaining a permission collection 
object associated with a plurality of permission objects, wherein said permission 
collection object includes a group validation method which, when invoked, indicates 
v^^cther a specified permission is encompassed by at least one permission represented 
by said plurality of permission objects. 

10. The method ofClaim3» wherein: 

the step of establishing a permission class includes establishing a permission subclass 

that is a descendant of a permission super class; and 
the permission super class defines an interface of said validation metiiod without 

providing an implementation for said validation method 

11. A computer-readable medium carrying one or more sequences of one or more 
instructions, wherein the execution of the one or more sequences of the one or more 
instructions causes the one or more processors to perform the steps of: 

wherein each permission object that is a member of said permission class represents at 
least one permission to perform an action; 

wherein said permission class includes a validation method; 

wherein said vaUdation method, when invoked for a particular permission object 

belonging to said permission class, indicates whether a specified permission is 
encompassed by a permission represented by the particular permission object 

12. The computer readable medium of Claim 1 1 , wherein: 

the step of estabUshing a permission class includes estabUshing a pa 

that is a descendant of a pernussion siqjer class; and 
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the pennissioQ super class defines an interface of said validation method. 

3 . The computer readable medium of Claim 1 2, further including one or more 

instnictions for performing the stq)s of: 

obtaining a first permission object, wherein said first permission object belongs to said 
permission subclass; 

obtaining a second object, wherein said second object belongs to a descendant class of 
the permission super class; and 

determining whether a first pennission represented by said first pennission object 
encompasses a second permission represented by said second object by 
invoking a validation method associated with said first pennission object 

14. The computer readable medium of Claim 13, wherein: 

the computer readable medium further includes one or more instructions for 

performing the step of receiving a request to perform a particular action; and 

the step of obtaining said second object includes the step of obtaining said second 
object based on said request to perform said particular action. 

15. The computer readable medium of Claim 14, wherein the step of determming whether 
said first pennission represented by said first permission object encompasses said 
second permission re^nesented by said second object includes sending to the validation 
method of said first object data that identifies the second object 

16. The computer readable medium of Claim 12, further including one or more 
instructions for performing the steps of: 

obtaining a first permission object, wherein said first permission object belongs to said 
pennission subclass, v*ercin said first pennission object specifies a first action 
and a first target; 

obtaining a second object, wherein said second object belongs to a dcsccndcnt class of 
the pennission super class, wherein said second object specifies a second acdon 
and a second target; aisd 
detennining whether a first permission represented by said first permission object 
encompasses a second permission represented by said second object by 
determining whether said first acdon encompasses said second action and 
detennining whether said first target encompasses said second target 

17. The computer readable medium of Claim 1 1, fimhcr including one or more 

mstnictions for performing the steps of obtaining a permis^on collection object 
associated with a plurality of permission objects, wherein said permission collection 
object includes a group validation method which, when invoked, indicates whether a 
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specified permission is encompassed by at least one permission represented by said 
plurality of permission objects. 

The computer readable medium of Claim 1 1 , wherein: 

the step of establishing a permission class includes establishing a permission subclass 

that is a descendant of a permission super class; and 
the permission super class defines an interface of said validation method without 

providing an implementation for said validation method. 



18. 

5 



19. A computer system comprising: 
a processor, 

10 a memory coupled to said processor, 

said processor being configured to establish a permission super class, 
wherein the permission super class defines an interfiice of a 
validation method; and 
said processor being configured to establish a permission subclass of the 
15 permission super class, wherein said permission subclass provides 

an implementation for said validation method, wherein said 
validation method, when invoked for a particular permission 
object belonging to said permission subclass* indicates whether a 
given permission is encompassed within a permission that is 
20 represented by said particular permission object 

20. The computer system of Claim 1 9, wherein die permission super class defines said 
interface of said validation metiiod without defining any implementation of the 
validation method 

21. The computer system of Claim I9,wherein: 

25 said processor is configured to create a first permission object in said memory; 

said first permission object belongs to said permission subclass; 
said processor is configured to create a second object in said memory* 
said second object belongs to a descendant class of the permission stqicr class; and 
said processor is configured to detemune whether a first permisdon represented by 
30 said first permission object encompasses a second permission represented by 

said second object by invoking a validation method associated with said first 
permission object 

22. Thccomputcrsystanof Claim 21, wherein: • 

said processor is configured to receive a request to perform a particular action; and 
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said processor is configured to create said second object by obtaining said second 
object based on said request to perform said particular action. 

The computer system of Claim 22, wherein said processor is configured to detennine 
whether said first permission represented by said first permission object encompasses 
said second permission represented by said second object by passing as a parameter to 
the validation method of said first object data that identifies the second object 

The computer system of Claim 19, wherein: 

said processor is configured to create a first permission object in said memory; 

said first permission object belongs to said permission subclass; 

said first permission object specifies a first action and a first target; 

said processor is configured to create a second object in said memory; 

said second object belongs to a subclass of the permission super class; 

said second object specifies a second action and a second target; and 

said processor is configured to determine whether a first permission represented by 
said first permission object encompasses a second permission represented by 
said second object by determining whether said first action encompasses said 
second action and determining whether said first target encompasses said 
second target 
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